查看原文
其他

【生活现场】从洗袜子到hbase存储原理解析

channingbreeze 互联网侦察 2019-04-02

郑重声明:漫画人物和故事情节均是原创,未经同意禁止任何形式的转载,侵权将进入法律程序。大佬除外。

欢迎大家转发文章,谢谢!

小史是一个非科班的程序员,虽然学的是电子专业,但是通过自己的努力成功通过了面试,现在要开始迎接新生活了。

对小史面试情况感兴趣的同学可以观看面试现场系列

今天,小史的姐姐和吕老师一起过来看小史,一进屋,就有一股难闻的气味。

可不,小史姐姐走进卫生间,发现地下一个盆子里全是没洗的袜子。

小史:当然不是,盆里的袜子满了,就先放到这个桶里,然后再继续装,等到桶里的袜子满了,然后才放到洗衣机里一次洗完,这样不仅效率高,而且节省水电费。

小史洋洋得意地介绍起自己洗袜子的流程。

小史一听就有点不高兴,全世界都黑程序员,没想到自己还没变成程序员就被自家姐姐黑了。

说完就进自己房间,把姐姐和吕老师晾在外面。小史姐姐也意识到不该拿程序员开玩笑,但现在也不知道该怎么办,就看着吕老师。

吕老师走进小史的房间。


【hbase是啥】


小史:别吹了,构建在hdfs上除了能存储海量数据之外,缺点一大堆,上次你给我介绍的hdfs缺点我可没忘啊,不支持小文件,不支持并发写,不支持文件随机修改,查询效率也低。


小史仔细回忆起hdfs来。


吕老师:hdfs确实有很多缺点,但是hbase却是一个支持百万级别高并发写入,支持实时查询,适合存储稀疏数据的分布式数据库系统。

吕老师:hbase主要用于大数据领域,在这方面,确实比mysql要厉害得多啊,它和mysql的存储方式就完全不一样。mysql是行式存储,hbase是列式存储。


【列式存储】


吕老师:没错,这就是行式存储系统存储稀疏数据的问题,我们再来看看列式存储如何解决这个问题,它的存储结构是这样的

小史:这个我看懂了,相当于把每一行的每一列拆开,然后通过rowkey关联起来,rowkey相同的这些数据其实就是原来的一行。

吕老师:你这里只说到了一个好处,由于把一行数据变成了这样的key-value的形式,所以hbase可以存储上百万列,又由于hbase基于hdfs来存储,所以hbase可以存储上亿行,是一个真正的海量数据库。

吕老师:这就是hbase的威力呀,还不只如此,其实很多时候,我们做select查询的时候,只关注某几列,比如我现在只关心大家的工资,传统的按行存储,要选出所有人的工资是怎么办的呢?


小史:哦,我大概明白了,原来是这样,所以hbase的查询效率也很高,但是我有个问题啊,如果我就要查我的所有信息,这是一行数据,hbase查询起来是不是反而更慢了呢?


【列簇】


吕老师:列簇,顾名思义,就是把一些列放在一起咯,在hbase中,会把列簇中的列存储在一起,比如我们把和工作相关的salaryjob都放在work这个列簇下,那么大概是这样的

小史:哦,我明白了,这样的话,一个列簇中的列会被一次就拿出来,如果我要查所有列的信息的话,把所有信息都放在一个列簇就好了。

(注意:hbase中,其实所有列都是在列簇中,定义表的时候就需要指定列簇。生产环境由于性能考虑和数据均衡考虑,一般只会用一个列簇,最多两个列簇)


【rowkey设计】


注:当然,有些中间件把sql翻译成hbase的查询规则,从而支持了sqlhbase,不在本文讨论范围内

小史:啊?这和我想象的不一样啊,如果我想查询工资比20w多的记录,在mysql中,只要用一条很简单的sql就行啊,这在hbase中怎么查呢?


吕老师:在hbase中,你需要把要查询的字段巧妙地设置在rowkey中,一个rowkey你可以理解为一个字符串,而hbase就是根据rowkey来建立索引的

不熟悉B+树的同学可以看这篇文章。hbase的HFile底层也是一样的原理。


吕老师:假设员工工资9999w封顶,查询的时候可能根据员工工资查询,也可能根据名字查询一个特定的员工,那么rowkey就可以这样设计

注意,以上rowkey是简化版设计,只是为了讲清楚范围查询。实际使用中由于rowkey需要考虑散列性,所以可能不会这么用。后文会具体探讨散列性。

吕老师:hbase提供了三种查询方式。

第一种是全表扫描,scan

第二种是根据一个rowkey进行查询

第三种是根据rowkey过滤的范围查询

比如你要查工资不少于20w的记录,就可以用范围查询,查出从startRow=0020stopRow=9999的所有记录,这是hbase直接支持的一种查询方式哦。

吕老师:这里要注意几点,首先,rowkey是按照字符串字典序来组织成B+树的,所以数字的话需要补齐,不然的话会出现123w小于20w的情况,但是补齐的话,你就会发现020w小于123w

小史:哦,明白了,这都很好理解,因为rowkey是字符串形式,所以肯定是按照字符串顺序排序咯。而且rowkey有点类似于mysql中的主键吧,所以保证其唯一性也是可以理解的。还有就是因为每个key-value都包含rowkey,所以rowkey越短,越能节省存储空间。

(注意,如果rowkey复杂且查询条件复杂,hbase还针对rowkey提供了自定义Filter,所以只要数据在rowkey中有体现,能解析,就能根据自己的条件进行查询)

小史:但是吕老师,我有一个问题啊,之前说过hdfs不适合存储小文件,而hbase中的一条记录只有一点点数据,记录条数却很多,属于海量小文件,存在hdfs中不是内存爆炸了吗?

【LSM三层存储模型】

小史:哦,这就像把盆里的袜子放到桶里一样。但是吕老师,如果数据量大的话,时间一长,就会有很多次刷写,不就形成了很多个小文件吗?这岂不又是海量小文件了?

不记得hdfs原理的同学可以温习一下,【生活现场】从生日请客到hdfs工作原理解析

吕老师:对了,hbase也是使用同样的思想,其实这就是WAL预写日志的思想,hbase也会将数据的操作先写日志,然后存到内存,哪天机器挂了,内存丢了,还能从WAL日志中将数据恢复。

【数据修改】


小史:不过吕老师,我还有问题啊,我记得hdfs是不能随机修改文件的,只能追加,那么hbase里的数据是不是写了之后就不能改也不能删除呢?

吕老师:删除同样是追加一条版本最新的记录,只不过标记这个数据被删除而已,查询的时候,看到版本最新的记录是数据删除,就知道这个数据被删了。

吕老师:哈,小史,你思考得非常深入,还记得LSM的第三层吗,hbase会在合并的时候,将这些用不到的记录删除掉,节省存储空间。

吕老师:不全对,其实hbase把合并分为两种,一种是小合并minor compact,这种方式只会将少数文件进行简单合并,不会进行数据的清理,还有一种是大合并major compact,这种方式会将大部分文件进行合并,并且清理数据。

吕老师:基本正确,但是你要知道,如果数据量大,这个过程是非常耗性能的,一般在生产环境都禁止大合并,否则在正常服务的时候突然来个大合并,整个集群可能资源被耗光,没法正常服务。

【hbase架构】



小史:hbase的架构似乎也是master-slave架构,和hdfs有点像,HMaster是用来管理集群,HRegionServer是真正存储数据的地方吧?

吕老师:啊,这块不太对,hbase在数据查询和写入的时候,其实并不是像hdfs那样询问HMaster。在hbase中,每一张表都会有元信息,这些信息也是被存储为hbase表,称为元信息表,也叫meta表,这是一种系统表。

小史:但是这又有个问题,既然meta表也是存储在hbase上,那么hbase又如何知道meta表存在哪个HRegionServer上呢?这岂不是一个鸡生蛋蛋生鸡的问题?

吕老师:小史啊,我说meta表是hbase表,是指meta表也是用rowkeyvalue的键值存储,但是我并没有说meta表在hbase上啊。其实meta表不是存储在HRegionServer上,而是存储在那个分布式协调服务zookeeper上面。

小史:哦,原来如此,所以meta表其实是在一个固定地方读取,然后根据meta表就知道数据在哪个HRegionServer上。但是zookeeper又是啥呢?

吕老师:其实HMaster的任务相对不繁重,但是却比较重要,它主要是通过调整和管理Region分布来实现HRegionServer的负载均衡。

【HRegionServer架构】


吕老师:其实Regionhbaserowkey上的切分,每个Region都可以通过startKeyendKey来确定rowkey的范围,一个HRegionServer上可能会有多个Region

小史:所以说数据是根据rowkey和一定的哈希规则,分散到不同的Region上面,而Region又是属于某一个HRegionServer上的,这个关系没错吧?

吕老师:没错,通过这里其实可以得出rowkey设计的另一个原则,就是散列性,rowkey的头几个字母,最好不要是一样的,不然会分布在同一个HRegionServer上面,导致这个HRegionServer的负载非常高,累死累活,其他HRegionServer却没事干。一般可以根据一定规则算一个数据的摘要,比如md5,把md5的头几位拼在rowkey的前面。

吕老师:哈哈,名词没讲过,原理可都是讲过的哟。比如这个Store,我们之前说过,一个列簇中的列是存储在一起的,对应到这里,一个列簇中的数据就是存到一个Store中。

吕老师:没错,这里StoreFile只是一个名字,它是以HFile的格式存储在hdfs上,HFile是一个存储格式,在新版本的HFile存储格式中,它就是一个类似B+树的索引索引形式。

【读取和写入流程】


1hbase client要写输入了,先从zookeeper中拿到meta表信息,根据数据的rowkey找到应该往哪个RegionServer

2、然后hbase会将数据写入对应RegionServer的内存MemStore中,同时记录操作日志WAL

3、当MemStore超过一定阈值,就会将内存MemStore中的数据刷写到硬盘上,形成StoreFile

4、在触发了一定条件的时候,小的StoreFile会进行合并,变成大的StoreFile,有利于hdfs存储

吕老师:其实当大量rowkey相近的数据都被分配到一个Region中,导致这个Region数据过大的时候,Region进行拆分,HMaster会对拆分后的Region重新分配RegionServer,这是HMaster的负载均衡策略。

1hbase client要读数据了,先从zookeeper中拿到meta表信息,根据要查的rowkey找到对应的数据在哪些RegionServer

2、分别在这些RegionServer上根据列簇进行StoreFileMemStore的查找,得到很多key-value结构的数据

3、根据数据的版本找到最新数据进行返回

【OLTP和OLAP】

吕老师:OLTP应用叫联机事务处理应用,就是类似银行转账等业务的,这类应用对事务要求比较高,而OLAP应用叫联机分析处理应用,比如推荐系统,是在收集了大量用户行为后进行分析,再得出结论的应用,主要侧重分析,对事务要求非常低。

【笔记】


小史把这次学习到的hbase的知识记了下来

1hbase是列式存储,和mysql的行式存储不一样

2hbase中有列簇概念,同一个列簇下的列存储在一起,在Region的一个StoreFile

3hbase是按照rowkey进行查找,要查询的字段要想办法放到rowkey

4hbase内部使用LSM三层模型进行存储,数据先写到内存MemStore中,内存达到一定阈值再刷写到硬盘StoreFile中,再满足一定条件时,小的StoreFile会合并为大的StoreFile

5hbase适合OLAP类的应用


学完hbase,记完笔记,小史开开心心地洗袜子去了。





生活现场是互联网侦察推出的现场系列中的另一个板块,旨在通过生活中的场景,来解释大数据微服务技术中的基本原理,希望对大家学习技术原理有所帮助。


往期回顾

【生活现场】从生日请客到hdfs工作原理解析

【生活现场】从打牌到map-reduce工作原理解析

【生活现场】从搬家到容器技术docker应用场景解析



    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存